NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c++/60

Internet Message Format | 1996-08-06 | 4.1 KB

From: James Kanze US/ESC 60/3/141 #40763 <[e-mail]>
Message-ID: <[e-mail]>
X-Original-Date: Wed, 17 Jan 96 12:06:51 +0100
Path: in2.uu.net!bounce-back
Date: 18 Jan 96 02:02:11 GMT
Approved: [e-mail]
Organization: -
In-Reply-To: [e-mail]'s message of 16 Jan 1996 10:43:59 PST
Newsgroups: comp.std.c++
Subject: Re: STL still in standard
References: <4dd7on$[e-mail]> <4dgrb4$[e-mail]>
X-Auth: PGPMoose V1.1 PGP comp.std.c++
    iQBFAgUBMP2qOOEDnX0m9pzZAQFgdgF6At59nRlH2pni3s1T0vjQUlaaNmYY15PF
    VsmVbh44Tq1Lpo+BJMOna5qFLEIg4+JB
    =GSPF

In article <4dgrb4$[e-mail]> [e-mail]
(Steve Clamage) writes:

|> In article [e-mail], Alain Dresse <[e-mail]> writes:
|> >I have heard about considerations on removing STL from the
|> >C++ standard because it is error prone.

|> >Could anyone confirm or deny this information ?

|> False.

|> The C++ Committee has been unanimous (or nearly so) in its acceptance
|> of STL. I do not believe there is any chance it will be dropped.

That's what I want to hear.

I'm curious in what way the STL is error prone.

From a user point of view, it is probably more error prone than
whatever class library your are used to using, because you are used to
the other library, and not STL.  The fact that it will be a standard
library, and that everyone will use it, will mean that in a couple of
years, just the opposite will be true.

The currently available implemention (from HP) is somewhat error
prone, and cannot be used in the presence of exceptions.  Given the
price that HP (a commercial firm, in business to make money) asks for
it, however, I hardly think anyone has a right to complain.  Their
implementation does offer a sound basis for a more solid
implementation, and has allowed many people to become familiar with
the idioms faster than would have otherwise been possible.

Safer implementations are possible; Cay Horstman, I think, has already
made one available.  Exception safe implementations are also possible.
(It is also an open question how far one wants to go here.  I would
accept, for example, that an exception from the comparison function
when inserting into a map results in undefined behavior; if comparison
can throw an exception, an STL map is perhaps not the appropriate
container.)

If the complaint is based on the fact that the Draft Standard is not
particularly clear, well, STL was added just before the Draft was made
public, so the text was added very hurriedly.  The (not officially
public) September draft is already significantly better; given the
quality of the people working on it, and the amount of work they are
investing, I see no reason to doubt that the final version will be OK.
(It will *NOT* be a tutorial, of course.  That is not the purpose of
an ISO standard.)

My pet peave, of course, is that there is no hint in the current
version as to the requirements of the template classes/functions when
the instantiation classe throws an exceptions, but I'm sure that this
is on someone's work list, somewhere, and will be addressed in the
final standard.  (In the meantime, I'd love a hint as to what
direction this will take.  Will an exception from a comparison
function cause undefined behavior?)

There is a lack of tutorial material at present, but this is only
because the library is new.  I expect that new C++ tutorials will
present vector<T> instead of the classical C style arrays, for
example.  (And you surely don't mean to imply that vector<T> is more
error prone than the C style arrays, do you?)

So why would anyone want the C++ standard *not* to include STL?

--
James Kanze         Tel.: [phone]        email: [e-mail]
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  Submission address: [e-mail].
  Contact address: [e-mail].  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]